SPAs: attack surface-are-us

Web designers love single-page apps (SPAs) because they load quickly and conceal connection deficiencies. They are also the cause of data breaches.

A web application that consists of a single HTML page has long been favored by web designers who need a focused and limited page form factor.

The single page app will load into the client browser quickly, and the content inside of the single page application can be dynamically updated. The SPA’s loading speed helps mask problems that are caused by a bad network.

From a security perspective, this advantage comes at a steep (and increasing) price, as recent research shows. Web apps in general and SPAs in particular are vulnerable to many well-known attack methods. According to the Verizon 2020 Data Breach Investigations Report (VDBIR), web applications were involved in 43% of data breaches.

“The widespread use of this technology,” writes Laura Paine on the blog of application security specialist Veracode, “provides a unique challenge for security teams looking to mitigate their risk of breach, as traditional scanning methods may not provide the necessary coverage.”

Paine points out that SPAs are especially vulnerable to the XSS style of attacks. According to UK-based firm Precise Security, almost 40 percent of all cyber-attacks in 2019 was performed by using cross-site scripting.

Danger foreseen, prevention failed

A danger foreseen is a danger that can be avoided, yes?

Far from it, says NTT subsidiary WhiteHat Security. In WhiteHat’s annual Application Security Statistics Report (2019), the researchers warn: “Despite widespread knowledge of this vulnerability and its broad and crippling impacts, the industry continues to fail to address XSS issues.”

While single page app vulnerabilities arise from many causes, not only from cross-site scripting, some are considered to be structural. One example is that SPAs can be opaque to automated security scan tools that observe network data flow.

Additionally, the large number of SPAs deployed over the years has vastly expanded the attack surface. That has made life easier for attackers and their automated tools: A form of attack that performs on one SPA may well work on another.

Source: Verizon 2020 Data Breach Investigations Report

All of the above begs the question: If web applications have become the #1 target for attacks, and vulnerable SPAs are ever more popular, what’s keeping companies from preventing such exploits  in the first place?

The answer, in short, is the browser.

How SPA Exploits Leverage Local Browser Vulnerabilities

At their core, the long-standing problems with SPAs are rooted in how such apps interact with the local browser, which processes web content on the user’s local device.

Given the tight integration of the browser with system resources, this opens the door for a wide array of methods to steal and manipulate user data. Common SPA exploit methods include:

• SPA attacks through XSS

The cross-scripting attacks mentioned earlier become possible because the traditional browser's HTML parser can be tricked to switch into an execution mode of operation (such as script, style, or event handlers) without encountering an explicit directive to do so.

That means the browser doesn’t encounter an "escape" (which denotes the end of HTML information) in the HTML source, thus allowing untrusted code to be processed without restrictions.

Including a fail-safe escape is a complex task - too complex, it turns out, for many web coders. There are so many unusual contexts within HTML that the specifics of escaping syntax rules can be overwhelming.

• SPA exploits using JavaScript

JavaScript introduces its own set of influencers when included inside the HTML that composes a SPA. Some JavaScript functions can never safely use untrusted data as input, even if the JavaScript has been previously "escaped".

This behavior makes the use of JavaScript in HTML potentially dangerous in most cases, requiring that a pre-vetted syntax be followed without variation.

While untrusted URLs that include the protocol "javascript:" should be on everyone's list of places to avoid, this unfortunately is not common knowledge. Such URLs will execute javascript code when used in URL DOM locations such as anchor tag HREF attributes or iFrame src locations.

Validating this kind of URL before it is performed cuts off one kind of problem, but there will always be something else popping up. What if the URL changes its content after it is assumed to be good, for example?

Dynamic use of JavaScript on SPAs may require some advanced techniques, such as the use of a "safe" JSON serializer. A serializer allows serialization of the JSON, making it a string of literal JavaScript. It can then be embedded in the HTML code as the contents of the <script> tag.

Even more advanced ways to do things are possible. AJAX ("Asynchronous JavaScript and XML") is one way a SPA can communicate with itself (or the net) without having to force a reload (along with the accompanying performance hit) of the SPA page.

Whatever the approach - we also cannot assume that all the latest security library updates are present in the user's browser. And even if they are - zero-day exploits happen. This is one more reason why SPAs need to be handled with care.

Wanted: an additional layer of security to prevent the SPA from compromising the local machine and network by way of the browser.

• SPA attacks through Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) are possible because a session cookie does not expire until the browser has been closed.

Having an unexpired cookie means that if a user logs in to one site and then navigates to another, then that user will still be authenticated against the first site on the second one.

The second site can then submit requests to the form on the first while pretending to be the user.

This is a prime example of how form forgeries get created: An HTML form may be changed from the version originally loaded by a browser. Other servers can modify the form on the path as the browser is redirected to different sites.

The same original valid form may present itself to multiple SPA apps and be modified, in turn, by malware.

Here again, the need for a centrally managed security framework becomes obvious. In this example, its role would be to generate and check for the presence of anti-forgery tokens in forms. There are different methods to do this, the technique can stop a forgery attack.

More SPA Security Concerns

A general overview (like this post) of the inherent risks of SPAs slights the details that may be encountered in a concrete problem.

Stephan Walther has examined the implications in more detail on his blog, where he looked into the interaction between ASP.NET and the SPA. His conclusion: “Whatever type of web application you build – regardless of whether it is a Single Page App, an ASP.NET MVC app, an ASP.NET Web Forms app, or a Rails app – you must constantly guard against security vulnerabilities.”

I’ve already touched upon the potential security impact of JavaScript on SPAs in this post. If that piqued your curiosity, Tala Security published a report in July of 2020. It quantifies some of the overall JavaScript risk, which the researchers found has increased this year.

The report states that "[t]he average website includes content from 32 third-party JavaScript vendors, up slightly from 2019. JavaScript powers richness and the framework of what renders on customer browsers, including images, style sheets, fonts, media, and content from 1st party source - the site owner."

The security firm found that 58% of the content displayed on customer browsers is delivered by third-party JavaScript. This can greatly affect a Single Page Application, since - as pointed out earlier - the SPA runs no validity checks on the code.

In light of these facts, what’s left of the initial appeal of SPAs?

Making web apps more usable through simplicity may not be as simple as first thought, and outright dangerous if we trust the local browser to do the right - secure - thing.

This blog was written by guest contributor Larry Loeb.

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for Security Now.